home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 7372 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB

  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: CHIP RAM speed test resul
  5. Date: 15 Apr 1996 13:54:05 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4ktkdt$8n1@sunsystem5.informatik.tu-muenchen.de>
  9. References: <4j6jv0$1im@serpens.rhein.de> <5827.6659T112T770@mbox.vol.it> <1996Apr2.234528.8971@scala.scala.com> <4k1kk3$i2q@sunsystem5.informatik.tu-muenchen.de> <4k2fbl$lag@serpens.rhein.de>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle5.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <4k2fbl$lag@serpens.rhein.de>, mlelstv@serpens.rhein.de (Michael van Elst) writes:
  15. |> fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) writes:
  16. |> 
  17. |> >ok, so why my 020 needs _12_ cycles , i.e. _846_ ns (!!!!) to load a
  18. |> >byte/.w/.l from chipmem ?
  19. |> 
  20. |> Maybe chip-bus contention ?
  21.  
  22. no. all chipdma off. "normal" dma-load (8 planes lores) won't change much.
  23. movem-read can get near to something like 10 cycles (because it does
  24. 5 cyles in fastmem ;)
  25. So acess in multiples of 2 cycles, max speed 8 cycles/acess.
  26.  
  27. |> 
  28. |> >why AGA got the curious quality that _any_ kind of chipmem acess is
  29. |> >just 2 times slower than it is in fastmem ?
  30. |> 
  31. |> This obviously depends on the speed of your fastmem.
  32.  
  33. my fastmem is 0waitstate to a 020-14, I should have said "just 2 times
  34. slower than max possible 020 acess". Still courious, how it manages to
  35. make any kind of acess 2 times slower.
  36.  
  37. I always had the impression that acess times are constants, not factors ;)
  38.  
  39. |> 
  40. |> >that's unlogic, because any acess should be delayed by a fix amount
  41. |> >of time. but: load 6 -> 12 cycles (difference: 6), store 4 -> 8 cycles
  42. |> >(difference: 4).
  43. |> 
  44. |> No. Writes are usually faster because a write cycle can complete while
  45. |> the CPU continues with internal operation. A read must complete because
  46. |> the CPU needs the data fetched.
  47.  
  48. my measurements include continous stores ;) I know a write to chipmem is
  49. 2 cycles if it is followed by 3 reg,reg operations ;)
  50.  
  51. It is really courious. Only the 6 cycles move.l (chip),(chip) is
  52. not done x2 to 12 cycles, because this would be against the
  53. "min 8 cycles chipmemacess" rule, so it is done in 16 cycles.
  54.  
  55. 2 rules:
  56.  
  57. a) ideal acess x2 (well, on a synced 020-14).
  58. b) if a) is less than "number of acesses x 8 cycles" then increase
  59.    to that number (this should be true for all cpus, meaning 8 14-MHz
  60.    cycles of course).
  61.  
  62. |> 
  63. |> >: perfectly aligned with the chip bus timing, or you would need a FIFO
  64. |> >: device to store the fetched data for when CPU could take it.
  65. |> 
  66. |> >again, beeing no expert at all, I can't stand the feeling that this FIFO
  67. |> >would be just another $0.2 TTLs. again, what about walker ?
  68. |> 
  69. |> No, it would be more than $0.2 (and very few TTL parts cost $0.2
  70. |> anyway).
  71.  
  72. Well, IMHO they should do it in walker. Like they did in A3000.
  73. Lots of people will use it for gaming, it will make sense.
  74.  
  75. |> >Am I missing something ?
  76. |> 
  77. |> Yes. "Adding some TTLs" needs lots of board space. And that is a price
  78. |> issue.
  79.  
  80. ah :\ 
  81. what about a inovative $3 sandwitch platine carrying all the TTLs ? ;)
  82.  
  83. |> 
  84. |> 
  85. |> 
  86. |> -- 
  87. |>                                 Michael van Elst
  88. |> 
  89. |> Internet: mlelstv@serpens.rhein.de
  90. |>                                 "A potential Snark may lurk in every tree."
  91. ------------------------------------------------------------------------
  92.    fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  93.  
  94.